1. Field
This disclosure relates to distributed communication systems, more particularly to a distributed application system using persistent stores and agents.
2. Background
Sun Corporation developed Java™, a three-part distributed means for computing. The three parts of Java™ are the Java™ programming language, the Java Virtual Machine™ (JVM) and the Java™ platform.
The Java™ programming language is just that, a programming language with its own syntax, structures and procedures similar to all other languages. It is the language in which Java™ applications such as applets, servlets, and JavaBeans™ components are written. A unique part of the Java™ language, however, is that it does not compile into machine-readable code, as most other languages do. It compiles into byte codes. These byte codes are interpretable by the JVM.
The JVM is the Java™ interpreter. Java™ programs are portable, being in byte code format, but they are only portable to platforms to which a Java™ interpreter has been ported. Fortunately, JVMs are freely available for virtually all types of systems, from desktop systems running Windows, Unix or Macintosh, to cell phones. All of these are capable of being a Java™ platform.
A platform typically identifies a set of application programming interfaces (APIs) typically defined by the operating system. A programmer writing a program to run on a specific operating system such as Windows would use a different set of APIs than a programmer writing a program for the Macintosh operating system. However, the Java™ platform provides APIs that run on any operating system running the Java™ platform. In some respects, the Java™ platform is an intermediate platform between the Java™ code and the operating system. It allows programmer to write a program once and run it anywhere.
Because Java™ code may run on several different operating systems and several different devices, it would seem a logical extension of this would be to connect these all together. Jini serves as the framework to make those connections. Jini is a set of specifications that allows different services to discover each other on a network. The specifications also allow these services to participate in operations on this network; the network is sometimes referred to as a community. However, to avoid confusion in further discussions the network will be referred to as a network or a Jini community.
Jini focuses on services. A service may also be thought of as a service interface. For example, a certain device such as a server may present an interface to the outside world that is the device API. This API interface is a service. Because Jini is a distributed framework, there will be clients and servers. However, these clients and servers only care about the interfaces that allow them access to the other clients and servers. The client or server will know about the particular service API, but does not care about the implementation. For example, there may be a printer on the network. Another member of the network will know that there is a printer API but does not care what kind of printer it is. The print service will allow the member to send a print job to the service and will handle the translation of the print job to the specific API for the printer.
One example of a Jini service is JavaSpaces™. Simply, JavaSpaces™ define a persistent store. In terms of the above discussion, a client that wants to use JavaSpaces™ only needs to know the JavaSpaces™ API. The client does not need to know the specifics on what type of server upon which the JavaSpaces™ is implemented.
From the above discussion, it would seem that the combination of Java™, Jini and JavaSpaces™ would provide an incredibly powerful, flexible means for establishing, running and reconfiguring networks. However, there are some limitations. For example, in order for Jini to function, as well as the JavaSpaces™, the Java™ language must exist in every device on the network whether client or server. Other minor weaknesses also exist, such as the required presence of a network, and the required presence of the devices that run JVM. Calls to a device that is temporarily unavailable are not allowed. Once a device goes off the network, anything addressed to it is removed as well.
The largest weakness in the current state of the art lies in the requirements of knowledge. Participants in a Jini community must know about each other's interfaces if they are to use each other. While the device sending the print job did not need to know the printer specifics in the above example, it did need to know the specifics of the print API. Service consumers and service providers must agree upon a common interface for the service to be used effectively. This restricts the application of these technologies to a fully distributed application system.